0 



'L 

n r r n r* OOO 





NAVAL POSTGRADUATE SCHOOL 

Monterey, California 





H l 



Application Developer’s Decision Support System 
Under A Common Front-End System Architecture 

by 

Charles C. Hansen 
September 1989 

Thesis Advisor Moshe Zviran 

Co-Advisor Chad Lee C. Grabow 

Approved for public release; distribution is unlimited. 



{2455% 



r 






REPORT DOCUMENTATION PAGE 



I R£=0 = ' StC-5 '• C.-.o - -A' O'- 

UK CL ASS I FI ~D 



’ D RtSTRiCT.v- MARmNGS 



i SEC 






I DECuA5S ,f .C- 



'.'c SC~ED^: 



3 DiSTR.B /'ON A v Ail^B w)T^ REPORi 

Approved for public release; 
distribution is unlimited. 



C P £ R F O R Mu N G C^jA \ Z~' » R E P O'- * ; 



3 MONi"OR(NG ORGANIZATION F:?On T NoMbt^S/ 



p^F f^lTgraduat'e ZA ' ,ON 



School 



OD O^ CE $> M3C* 
(It applicable) 

0*7^ 



'’a NAVE 0 - MONITORING ORGANIZATION 

Laval Postgraduate School 



f ADDRESS (Ot>. S(<st€ d r 3 £i p CooeJ 

iXonterey, CA 535^-3-5000 



7c ADDRESS (C/ty, State, and ZIP Code) 

Monterey, CA 93943-5000 



f NAVE 0 s C J\>NG S ? ONSO-*NG 
organization 



Sr o :: CE Symbol 
f/f applicable) 



9 PROCUREMENT INSTRUMENT IDENTIFICATION NUMBER 



ADORE SS (Gr> Sra*e. ana Z r Ccj f 



‘ r SO'jRC: : C J\DNG V- : p 



PROGRAM 


PRO jEC T 


TA$r 


;.o^ UNIT 


ELEMENT NO 


NO 


NO 


ACCESSION NO 



T»T W E (/nc/ua? 5eco.*»: } Gass t ;a**on. 

Application LeveLooe: 

TP->^ z-' y» T — ^ 'T* -- q — o ”'■* A -*'» t 



s Cec 



isicn Support System Under A Common 



PERSON- . ~V~ 

Har sen , 



• a TvRE 0 : PER?-’ 

s, s 2 e r 1 s Thesis 


’ ME „G .e-EE 


’4 D A r E G : PE pQR’ rea r Monrn Da>/ 

September 155? 


139~ " 


, i^: fc tVt*/A : * \_rn~ ■. The views expressed : 

nd d q net y* p p p p c -■ *■ - ^ ^ noli^v 

.3. Sovernm.er.- 


Ln this thesis are tr.ose of tne author 
of the Department of Defense cr the 


- 


:^r :V E“ Y3 Conr/n Le on reverse if ne(€ssa r ; and ioent / f t o> b-or> number' 



i AES' P-C" 'Conr.nyp c 

Application 
■rearing effic 
.ave tried 1 
.icraries, but 
.polication re 
'nder the Comm 
lores Central 
iave access to 
.evelopment ti 

A Decision 
:aining access 
efforts is des 
'he creation o 



r re.c sc ’ npcessa'’; a°a /o c n:,? c r £><oc' no.roe:; 

s development personnel have been confronted with the task of 
iert applications to meet the needs of the end-user. Developers 
meet these needs by building their own individual routine 
the wiae range of skill levels and the large backlog of 
quests have kept developers and end-users largely unsatisfied, 
on Front-End System Architecture being installed at the Karine 
Design And Programming Activity Kansas City, Mo. developers will 
a tool box of common functions that will help reduce 
e for all levels of applications. 

; System (DSC) designed to aid development personnel in 
; data and functions necessary for their development 
■ the Karine Cores to support Manpower and °ay systems, 
a DSS will entail gathering data concerning access 



u. r . 



tc 

r>c ^ nt 

f such 



K D yo B. 1 UN - vA .-r ' • ArB'-A ' 

ry y-.r pz' r \ •• -r* ^ >A # .* : 



abs'ra:’ sec.r t - c.ass f 
1 u 



7 iO r 



4 . a NAY; *J- ^ ;"'/o : ‘.J * J a 

’.V c’r 7 - - - -*n - v 



: C > t 



-ONE i/nouoe Are* ^oo*u 

' ^ mG 



. c S*M3_ 



)D FORM 1473. -- v 



c* . Cr * * e** a 

Z * J-'a a-c ?DSO <?**- 



a ' rr. 



r 1 0"<e? I 9* 6—40(1 ?* 

i <5 Q ^ T r!t ^ 



T 'n class! 



SECURITY CL AMI FI CATION Of THU R*Q* 



patterns to tool box 
tool box 
2. o £ i c an d n 
transaction 



functions and database elements, definition 



functions to be utilized by 



rocessinn 



:r use 



the DSS, and definition 
determining all related 



■ :+ icn of specifi 
of the decisio 
elements of a 



T r> n Q c- j -f ^ Q j 

SECURITY CLASSIFICATION OF THIS PAGE 



Approved for public release; distribution is unlimited. 



Application Developer's 
Decision Support System 
Under A Common Front-End System Architecture 

by 



Charles C. Hansen 

a 

Captain, United States Marine Corps 

B.A., University of Washington, 1984 

Submitted in partial fulfillment 
of the requirements for the degree of 

MASTER OF SCIENCE IN INFORMATION SYSTEMS 

from the 



NAVAL POSTGRADUATE SCHOOL 
September 1989 



ABSTRACT 



Applications development personnel have been confronted 
with the task of creating efficient applications to meet the 
needs of the end-user. Developers have tried to meet these 
needs by building their own individual routine libraries, but 
the wide range of skill levels and the large backlog of 
application requests have kept developers and end-users 
largely unsatisfied. Under the Common Front-End System 
Architecture being installed at the Marine Corps Central 
Design And Programming Activity Kansas City, Mo. developers 
will have access to a tool box of common functions that will 
help reduce development time for all levels of applications. 

A Decision Support System (DSS) designed to aid 
development personnel in gaining access to the data and 
functions necessary for their development efforts is desired 
by the Marine Corps to support Manpower and Pay systems. The 
creation of such a DSS will entail gathering data concerning 
access patterns to tool box functions and database elements, 
definition of specific tool box functions to be utilized by 
the DSS, and definition of the decision logic and rule 
processing for use in determining all the related elements of 
a transaction. 
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I . 



INTRODUCTION 



The U. S. Marine Corps' large scale data processing 
efforts are centered on three large databases operating on 
an IBM mainframe computer using the wide area network known 
as the Marine Corps Data Network (MCDN) . These databases 
are separated into three main functional areas: Manpower, 
Pay, Fiscal; Logistical Support; and Budget and Finance. 

Each of these functional areas is under the control of a 
system sponsor, and the development effort within each is 
handled at a separate Marine Corps Central Design and 
Programming Activity (MCCDPA) . These MCCDPA's are subject 
to a high rate of personnel turnover. Personnel are 
constantly moving between MCCDPA's and other data processing 
activities. This guarantees an influx of new people with 
changing ideas for each unit. However it also means a 
consistent loss of expertise at each sight as personnel who 
are familiar with a system receive orders and move on to 
other installations. In many cases, the only expertise or 
useful experience that a new individual brings with him/her 
when he/she transfers is that of the operating system, 
database management system, other software languages, and 
functions of the MCDN. The skills and knowledge from one 
functional area are rarely applicable to another. 
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The database management system and fourth generation 
language utilized by the Marine Corps in the development and 
maintenance of these systems are Software AG's ADABAS and 
NATURAL. Additionally, support of other procedural 
languages such as COBOL is still required due to the large 
base of existing applications. The development efforts for 
the new database systems and the maintenance requirements 
for the existing applications have put a strain on the 
Marine Corps' data processing personnel and assets. In an 
effort to alleviate some of this burden, development 
personnel in the manpower and pay arena are interested in a 
project by the Department of Energy's Idaho National 
Engineering Laboratory (DOE INEL) . 

The DOE INEL has developed a System Architecture (SA) 
for IBM mainframe computers environment that gives users at 
all levels a common view or feel of the system regardless of 
the specific machine type, operating system or communication 
processor they are working on. This SA provides the user 
with a series of menus that contain unique access choices 
based on each user's security profile allowing access to 
data and functions. Access to other data elements through 
SA is prevented by restricting each user's visibility within 
the system to those transactions and items necessary for 
him/her to accomplish his/her daily work. 
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Additionally, personnel are provided access to a tool 
box of common functions that can significantly reduce 
program development and maintenance time. The tool box is 
centered on a logical transaction concept which is defined 
as the mihimum amount of work required to perform some 
aspect of an automated process. Each transaction or process 
within a system is analyzed to determine what actions are 
associated with it. Once identified, they are used to 
define the logical transaction that is contained in the tool 
box. After the logical transaction has been defined, the 
developer does not need to rely on his/her memory or spend 
time tracking through system manuals to ensure that a 
transaction he requires for an application is complete. 
He/she simply accesses the tool box for the transaction and 
is insured of the completeness of the transaction based on 
its presence in the tool box. 

The SA provides a user with several tools to enhance 
his/her performance and productivity. Metrics at the DOE 
INEL have documented 38% productivity gains with the SA. 
(Bell R.S. et al, 1988) 

The U. S. Marine Corps' Real Time Finance and Manpower 
Management Information System (Real FAMMIS) design team is 
working with the DOE INEL on the transfer of the SA 
technology. The technology transfer will be accomplished in 
three phases. Phase I is limited to the manpower and pay 
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arena at the Marine Corps Central Design and Programming 
Activity (MCCDPA) Kansas City, Missouri and was scheduled 
for 30 May 1989. Phase II will incorporate the SA 
technology Marine Corps wide using the Marine Corps Data 
Network (MCDN) under the title of Common Front-End System 
Architecture (CFESA) . Testing of Phase II is scheduled for 
1 October 1989. Phase III is scheduled for the 1st quarter 
of CY1990 and is planned to include a Decision Support 
System (DSS) capability or tool box item to support 
development personnel in the manpower and pay arena. 
Development of DSS ' s for the other functional areas are 
anticipated to take place at a later date. If desired, the 
functional manager or responsible MCCDPA, using the 
framework established for the Application Developers DSS for 
the manpower and pay arena, will develop their respective 
capability. 

The DSS for the manpower and pay arena will be a support 
tool designed to provide developers with rapid and timely 
access to the data and functions necessary to complete their 
development projects. It will function as an expert system 
to meet developers' needs by asking the developers to 
specify the general functions needed for their development 
project, such as ADD or UPDATE, and the primary data 
requirements, such as PAY or PERSONAL data. The DSS will 
use this initial specification to access the tool box to 
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retrieve all the related logical transactions for the 
particular area of concern. Once all of the logical 
transactions have been retrieved, the developer will be able 
to review, evaluate and order them for use within the 
particular application he/she is developing. At this time, 
the developer may choose to reject entire logical 
transactions or portions thereof if they are not necessary 
for a particular project. He/she may also create 
transactions of his/her own which meet the specific 
requirements of a project. 

Project development without the use of a tool box of 
common functions is a lengthy and painful process. It 
becomes almost unmanageable when it involves data that spans 
multiple related functional areas like manpower and pay. 

Each developer is required to identify all of the aspects of 
each transaction on his/her own. This is a difficult 
process at best and it usually requires several iterations 
before it is done correctly. 

Currently, application developers must rely on their own 
memory, search through system manuals, or query a fellow 
programmer (the duty expert) when developing applications to 
insure that all related aspects of a transaction are 
addressed in their application. This can take an inordinate 
amount of time in the case of searching through system 
manuals, and typically ties up two programmers when 
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consulting the duty expert. When this happens, nothing is 
done to reduce the programming burden being faced throughout 
the data processing community. An expert system with access 
to a tool box of logical transactions can eliminate much of 
this duplication of effort in identifying and coding all of 
the related aspects of a transaction. Another benefit of 
using an expert system to access a tool box of logical 
transactions is that the testing of the code that makes up 
the transactions has already been accomplished. Using code 
that has already been debugged will reduce the amount of 
time it takes to test a program containing these logical 
transactions . 

Expert systems technology will also help to address the 
problem of loosing personnel through Permanent Change of 
Station Orders. With an expert system in place, much of the 
expert's knowledge will remain behind when he/she is 
transferred. This will aid in the training of new personnel 
on the system and speed up the development of applications 
as well. 

The CFESA provides an excellent environment in which to 
implement an expert based system. It provides a single 
system image for the user to work in that will be familiar 
to him/her no matter where he/she is operating from. The 
access to a tool box of common functions is already in place 
within CFESA, with the only addition required being the 
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decision logic and rule processing, and the inference 
mechanism to drive the system. Adding an expert system that 
will drive the initial transaction identification process 
for a system should allow for additional increases in 
productivity over and above the 38% increases achieved by 
the DOE INEL. 

The addition of a DSS to the manpower and pay arena will 
provide a developer with a series of transactions that are 
applicable to the project he/she is working on based on the 
specifications provided. A developer will then refine and 
combine the initial logical transactions to produce a 
prototype system for a user to evaluate and comment on. 

This will provide a developer with an immediate time savings 
at the beginning of a project by giving him/her a starting 
base for the application. Through the use of the 
Application Developers DSS and prototyping for developing 
new systems end users should be able to reap the benefits of 
a new application earlier than under current development 
methods, and application developers should finally be able 
to reduce the backlog of development requests he/she is 
currently facing. 

In many cases, it is difficult to evaluate the 
effectiveness of a DSS, but when dealing with a DSS of the 
expert system variety it is often much easier. Evaluation 
of the Application Developers DSS should be easy to 
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accomplish by comparing the current backlog of application 
development requests with the backlog of requests after the 
system is in place. A reduction of the turnaround time for 
application development should be evident after the system 
is in place. Additionally, the CFESA provides the 
capability to monitor the actions taken by any user or 
system operating within its environment. This serves two 
purposes; it provides an audit trail to track actions within 
the system, and the ability to generate system wide 
statistics for the computer centers operation staff to use 
to refine the systems operation. It can also provide the 
basic statistics for system budgeting and cost accounting. 
The use of the system monitor to record access information 
for the Application Developers DSS to the tool box would 
give an indication of the number of accesses the Application 
Developers DSS makes to the tool box and the average number 
of transactions each access to the tool box generates. 

These statistics can easily be compared to current 
development metrics such as lines of code to determine the 
efficiency of the Application Developers DSS in developing 
applications . 

The creation of a DSS to aid application development 
personnel will entail definition of specific tool box 
functions and the decision logic and rule processing to be 
used by the DSS. Its purpose is to aid development 
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personnel in gaining access to the data and functions they 
need in their programs to meet the needs of the end-users. 
Once the initial prototyping of the system is complete, it 
is anticipated that system development will follow two paths 
concurrently : 

• Further development within the Manpower and Pay 
functional area 

• Expanded functional area support by being used as a 
basic framework for personnel to use in developing 
expert systems to support efforts in the fiscal and 
logistical support functional areas 

Within the manpower and pay arena, interest already 
exists in developing expert systems to support end-users in 
individual applications. The Application Developers DSS 
will provide the basic mechanisms and specific tool box 
functions that will be necessary to drive these specific 
applications . 

Subsequent chapters detail specific aspects for a DSS to 
aid application developers in the manpower and pay arena. 

• Chapter 2 describes the basic background concerning 
application development within the Marine Corps and the 
basic characteristics of a DSS as well 

• Chapter 3 addresses the current environment at the 
MCCDPA Kansas City, Missouri and the addition of the 
Common Front End System Architecture 

• Chapter 4 addresses the decision logic and rule 
processing that will drive the functioning of the DSS 

• Chapter 5 outlines the components in the model/knowledge 
base of the DSS 

• Chapter 6 covers the functional requirements definition 
of the proposed DSS 
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Chapter 7 addresses the integration of the data, dialog, 
and modeling capabilities within the Common Front-End 
System Architecture 

Chapter 8 addresses the Conclusions and Recommendations 
concerning the development of the Application Developers 
Decision Support System 
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II. BACKGROUND 



A. DSS ROLE AND ENVIRONMENT 

Identifying all the aspects of what appears to be a 
simple transaction can become an elaborate and incredibly 
complicated task in a large scale information systems 
development project. Many sources must be checked to 
discover all the elements that might be effected by a single 
transaction, such as a promotion, and most organizations 
have strict guidelines that must be followed during the 
software development project. It often takes a junior 
programmer many hours of exhaustive research coupled with 
several iterations of coding and testing before it is 
correct . 

Information systems development projects within the 
Marine Corps are currently governed by Marine Corps Order 
P5231.1A: Life Cycle Management For Information Systems 
Projects, and IRM-5231-01: Information Resources Management 
System Development Methodology - Overview. The primary area 
of concern addressed by these documents is the large scale 
mainframe database developments using the MCDN. During 
project development, analysts and programmers are required 
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to follow the specification contained in these, and 
subsequent documents, in addition to trying to meet the 
needs of the end-user for whom the program is being 
developed . 

Care must be taken during development to ensure that all 
aspects of a transaction are dealt with properly and 
completely. In the manpower and pay arena, a single 
transaction may effect elements contained in two separate 
ADABAS physical files. Identifying all the aspects 
contained within one transaction can take an enormous amount 
of time and effort on the part of a junior programmer. 
Numerous sources exist for identifying the data affected by 
a transaction, including other Marine Corps Orders, 
previously developed programs, and any duty experts that may 
be available for the programmer to consult. When the 
frequent movement of personnel is taken into account, it is 
often a miracle that anything is accomplished at all. Any 
expertise that an analyst or programmer may develop during 
his tour at an installation is often lost when he/she moves 
on to another site, and there is no guarantee that his/her 
replacement will come in with anywhere near his/her level of 
knowledge. This means that each new programmer must often 
re-learn the knowledge that an outgoing expert has developed 
with minimal turnover involved. All the factors that must 
be considered during the development process add to the 
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complexity of the task, and tend to increase the amount of 
time required in the development process. 

The CFESA environment provides a good basis for 
developing a DSS . The single system image and the 
consistent access format are well equipped to be adapted for 
use as the dialog manager within a DSS. Once the 
development system is invoked, a query/response type of 
dialogue can be initiated within the CFESA to provide the 
DSS with the information it needs to access the tool box. 

The tool box of common functions within the CFESA will 
provide the model base of logical transactions. Once the 
system has received the input from the developer, it will 
access the tool box and provide the developer with a list of 
the transactions necessary to complete some aspect of an 
automated process. The CFESA also provides a facility for 
performing maintenance on the tool box that will allow for 
modification of and additions to the logical transactions 
throughout the life of the system. The database portion of 
an expert system is different than what is considered the 
database portion of a DSS. Within an expert system, all the 
database portion is used for is a temporary work space to 
use while collecting and collating the users input and the 
system responses. This can be provided quite easily by 
utilizing some temporary working storage for the user during 
the operation of the system. The CFESA also provides a 
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suitable environment within which to build the decision 
logic and rule processing that is necessary to power the 
inference engine within an expert system. 

A DSS to support application developers will fill the 
role of a duty expert within a functional area such as 
manpower and pay. When provided with the specifics of an 
application, it will be able to access the tool box and 
provide the user with a list of potential transactions much 
faster than the user could develop on his own. In this way, 
it will serve to lessen the impact of experienced 
programmers being transferred to other installations. Using 
a query/response format to obtain the required input from 
the user will allow the system to function much like a duty 
expert. The decision logic and rule processing within the 
inference mechanism could utilize data driven forward 
chaining in order to identify all the applicable data 
elements, functions and procedures to meet the needs of the 
transaction. A secondary benefit that will be realized by 
the use of an expert system is the faster development and 
training of junior programmers. The system will help less 
experienced programmers to obtain a grasp of the functions 
and related attributes within a given functional area. It 
will accomplish this without removing a second programmer 
from his/her development efforts as is normally the case 
when a real duty expert is consulted for information. 
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Moreover, such a DSS is expected to have a major impact 
on the amount of time required for project development. It 
will reduce the amount of time required to identify all the 
aspects of an automated process and provide an increase in 
programmer efficiency by allowing them to efficiently 
utilize a pre-programmed library of common functions. 
Performance/ impact of the system should be readily assessed 
by an increase in programmer productivity and a reduction in 
the amount of time a users request for an application spends 
in the development process. Use of the expert system can be 
measured within the CFESA by utilizing a transaction log 
type of facility available within CFESA to record the number 
of accesses made to the system and the amount of time 
required for the system to process a request. This 
information can be compared with the increase in programmer 
productivity to determine how effective the system is at 
fulfilling the role of a duty expert within a given 
functional area. 

B. DSS DESIGN AND IMPLEMENTATION PLAN 

The design of the Application Developers Decision 
Support System differs somewhat from methods used for 
designing MIS. Traditional design methodologies (i.e. 
flowcharts, HIPO) have proven deficient for developing a DSS 
(Sprague and Carlson, 1982) . Structured design 
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methodologies often result in a mismatch between the 
capabilities of the DSS and the requirements of decision 
makers or decision making. They do not have balanced 
strength in dialog, data, and modeling capabilities because 
users cannot specifically define the decision support 
requirements in advance. An approach to systems analysis 
which is intended to identify requirements in the dialog, 
data and modeling capability areas of a DSS is based on a 
set of four user-oriented entities: Representations, 
Operations, Memory Aids and Control Mechanisms (ROMC) . 
Representations help conceptualize and communicate the 
problem or decision situation; operations analyze and 
manipulate those representations; memory aids assist the 
user in linking the representations and operations; and 
control mechanisms allow the user to handle and use the 
system. This approach to system analysis is known as the 
ROMC approach. It is a process-independent method that 
helps to reduce the gap between decision support 
requirements and DSS capabilities (Sprague and Carlson, 
1982; Turban, 1988). 
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Since the system is based on expert systems technology, 
a hybrid of DSS, the components that make up the system 
differ from other DSS. To the extent possible, a complete 
Representations, Operations, Memory Aids, and Control 
Mechanisms description of the system follows: 

1. Representations 

• Data Dictionaries 

• Marine Corps Orders 

• System Manuals 

• Existing Programs 

• Other Programmers 

2. Operations 

• Spider Diagram of Related Functions (Barrett and 

Beerel, 1988) 

• Event Screen Maps (Planning Analysis Corporation, 

1988) 

3. Memory Aids 

• Tool Box of Common Functions 

4 . Control Mechanisms 

• Common Front-End System Architecture 

• Decision Logic and Rule Processing 
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The Representations comprise all the sources that a 
programmer/analyst has at his/her disposal to consult during 
application development. An in depth review of these 
sources is necessary to identify all the elements that are 
related to a specific transaction so that the relations can 
be included in the tool box of common functions. 

The Operations required in the system are shown in the 
Spider Diagrams contained in Appendix A and the Event Screen 
Maps contained in Appendix B. Appendix A details the 
sequence of events for one leg of the entire system and 
Appendix B contains diagrams detailing all the events in the 
system. Implementing these operations will allow the user 
to provide the specifications necessary to access the tool 
box and determine the data elements, functions and 
procedures that may be applicable to the type of application 
he/she is developing. 

The Memory Aids contained in the tool box of common 
functions represent all the related aspects of a transaction 
as identified by the objects listed in the Representations. 
By referring to the tool box an application developer can 
quickly identify all the related data elements and save the 
time that would have initially been spent on searching 
through the manuals to find them. 
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The Control Mechanisms for the proposed system are 
contained within the Common Front-End System Architecture 
and the rule processing and decision logic utilized in the 
inference mechanisms processing. The CFESA provides the 
environment within which the entire system functions, and 
the update and access mechanisms for the tool box of common 
functions. Additionally, the CFESA provides for the smooth 
integration of all the aspects of the expert system. The 
rule processing and decision logic control the processing of 
the inference mechanism for the system. The decision logic 
will be used to drive a query/response dialogue with the 
system user to provide the initial input to the inference 
mechanism. The inference mechanism will then utilize that 
input to search through the model base to identify the 
related data elements, functions and procedures within the 
tool box for an application developers use. 

Functionally, the Application Developers DSS will 
include dialogue, data and modeling components as follows: 

• Dialog Component 

The DSS dialog will be handled in a Query/Response 
format where the system queries the user to gather input 
concerning the area of application to use to drive the 
inference engine. A typical session between the system 
(DSS) and an application developer (AD) might begin as 
follows: 
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DSS : What is the primary functional area of the 

application? 

1. ) MANPOWER. 

2 . ) PAY . 

3 . ) BOTH . 

AD: 1. 

DSS: What is the type of transaction to be performed? 

1. ) Add a record. 

2. ) Delete a record. 

3. ) Output a record. 

4. ) Update a record. 

AD: 4 . 

DSS: What is the primary element of concern? 

1. ) Grade change. 

2. ) Duty status. 

3. ) Dependents status. 

4. ) Local commanders information. 

AD: 1. 

DSS: What type of grade change? 

1. ) Promotion. 

2. ) Demotion. 
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Using this style of dialog will allow the system to 
obtain the information it requires to function, and will 
do so in a manner that is easy for even novice users to 
understand and respond to. It also allows the system to 
respond to queries from the users asking for 
explanations why a specific question is being asked or 
how the system reached a particular conclusion. 

• Data Component 

Normally, the data component of a DSS is represented 
by a database of one type or another. Within the 
Application Developers DSS, the database serves as a 
temporary working storage space where it acts upon the 
inputs from the user and combines them with the tool box 
components in order to respond to the users request. 

• Model Component 

The model component represents the knowledge store 
within the system. Within the Application Developers 
DSS the knowledge is represented by the rule processing 
and decision logic working in conjunction with the 
components contained in the tool box of common 
functions. The CFESA provides the facility to make 
changes to the model base allowing the system to grow 
and adapt to the needs of the users. 
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Figure 2-1 contains a diagram showing how the resources 
available within the DSS environment are mapped onto the 
functional components described above. The CFESA provides 
the framework within which the DSS functions as a whole, and 
it also provides key components for use by the individual 
Dialogue and Model components. Additionally, the model 
component contains the heart of the DSS, the tool box of 
common functions and the inference mechanism. These two 
items are the parts of the system that actually simulate the 
reasoning of a duty expert to provide a response to a users 
request. While the user may view the dialogue component 
he/she deals with as the system, the majority of the design 
effort is centered here to provide accurate and meaningful 
results. The data component shown on the map actually holds 
a minimal amount of data in the form of the decision logic 
and rule processing. There is some interface between the 
functional area's data dictionary and the tool box of common 
functions. This is accomplished within the temporary work 
space that is designated within the expert system in order 
to handle the users input and formulate the systems replies 
to the users queries. 
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Resources/Functional Components 




Figure 2-1 CFESA Components 

Figure 2-2 contains a diagram showing how the 
implementation process for an expert system should be 
handled. The most important activities within the process 
are acquiring and structuring the knowledge. This is the 
time when you are working closely with the duty expert and 
potential users trying to adapt the system to meet their 
needs. Care must be taken during this phase to insure 
cooperation between all parties. Again it is important to 
remember that this is an iterative process, as depicted in 
the diagram, and change is expected to occur. 
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Implementation Process 



clarification 
and revisions 



revisions 



changes and 
extensions 




Figure 2-2 Implementation Process 



(Barrett & Beerel, 1988) 
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III. ENVIRONMENT 



A recent study (Peat, Marwick, Main & Co., 1987) 
analyzed the benefits of a user interface that was found to 
be easy to use. The benefits identified by the study fell 
into four broad areas. 

• Productivity gains were realized by an improvement in 
throughput, increased quality of product, and improved 
planning, communications, and control due to a system 
that was easy to use 

• Ease of use was found to be an asset in a system since 
it promoted use of the system rather than acted as a 
roadblock to the users 

• Ease of training made the system easier for the users to 
get started with and once they had learned one 
application it was easy to add on others since they had 
the same feel due to a common interface 

• Executive use of the system was found to be enhanced as 
a result of the ease of use and ease of training 
features. The ability to quickly master the operation 
of a system allowed key executives to plan, communicate, 
and control their projects and resources which provides 
competitive and strategic value to an organization 

The benefits identified in the study are summarized in 
Table 3.1. 
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Good User Interface Benefits 

Productivity Gains 

- Throughput gains. 

- Quality gains. 

- Planning, Communications, and Control gains. 
Ease of use promotes use. 

Ease of training. 

Executive use. 



Table 3.1 Interface Benefits 

The ability of an easy to use interface to increase 
productivity and promote use of a system is the reason 
behind the inception of the Common Front End System 
Architecture (CFESA) . 

The CFESA is scheduled for implementation at the MCCDPA 
Kansas City, Mo. during the fall of 1989. The environment 
that it will be operating on is contained in Table 3.2. 
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HARDWARE: 


SOFTWARE: 


IBM 3084 Quad Processor 


MVS/XA 


IBM 3380 DASD 


Top Secret 


NCR Comten Front end Processor 


UCC - 7 


Line Printers 


UCC - 11 


Tape Drives 


VTAM 

TSO/E 


Other associated peripherals 


CICS 
ROSCOE 
COMPLETE 
Natural 2.1 
Adabas 5.0 




Other miscellaneous compilers 
utilities and application 
packages 



Table 3.2 MCCDPA Environment 



The CFESA is designed to standardize the computer 
interface and provide a single system image within a 
computing environment. The primary goal of the single 
system image is to provide a friendlier, easier to use 
interface that promotes system use rather than acts as an 
obstacle to it. 

The CFESA is centered around a menu system that provides 
a user with a unique choice of functions based on what 
he/she is authorized to access. The menu system is flexible 
in the sense that it allows novice users the ability to step 
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down through each level of menus to get to the function or 
data he/she needs to access, yet will allow an experienced 
user to do a direct transfer to the function or data without 
utilizing each of the intermediate steps. The security 
facility within the CFESA is provided by a centralized 
security file that is accessed each time a user logs onto 
the system. The specific access level for the user is 
contained in the file and determines what functions he/she 
is provided within his/her menu structure. This further 
enhances system security by preventing a user from seeing 
functions that he/she is not authorized to 
access. (Linsenman, 1987) 

Additionally, personnel are provided access to 
development aids in the form of a tool box of common 
functions that can significantly reduce program development 
and maintenance time. One such aid is the standard 
navigational capabilities given to the user through the use 
of Program Function (PF) Keys. Actions such as the 
immediate log-off from the system, transfer to any other 
authorized transaction in the system, and return to the 
previous menu are effected with a single keystroke. 
(Linsenman, 1987) The ability to utilize these aids saves 
time on the users part and provides a quick and standard 
method of execution which further enhances the single system 
image. Table 3.3 contains a summary of the functionality 
provided by the CFESA. 
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SYSTEM ARCHITECTURE CONCEPT 



* SINGLE SYSTEM IMAGE 

- ONE LOGON PROVIDES ALL ACCESS 

- CONSISTENT USER INTERFACE 

# STANDARD MENU SCREENS 

# COMMON AUDIT FUNCTIONS 

# COMMON HELP AND ERROR HANDLING 

# STANDARD USE OF KEYBOARD 

- MACHINE INDEPENDENT 

- SOFTWARE INDEPENDENCE 

- INTRA-APPLICATION COMMUNICATIONS 

* SECURITY CONCEPT 

- STANDARD SECURITY IAW TOP SECRET 

* INTEGRATED DATA RESOURCE 

- REAL FAMMIS DATA BASE 

- CURRENT DATA BASES 



Table 3.3 CFESA Concept 



The tool box is centered on a logical transaction 
concept which is defined as the minimum amount of work 
required to perform some aspect of an automated process. 
Each transaction or process within a system is analyzed to 
determine what actions are associated with it. Once 
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identified, they are used to define the logical transaction 
that is contained in the tool box. Once the logical 
transaction is defined, the developer does not need to rely 
on his/her memory or spend time tracking through system 
manuals to ensure that a transaction he/she requires for an 
application is complete. He/she simply accesses the tool 
box for the transaction and is insured of the atomicity of 
the transaction based on its presence in the tool box. If 
five records need to be created to add an item to a 
database, then the creation of the five records is a logical 
transaction. Any less data indicates an incomplete 
transaction, and any more indicates a repeat of the 
transaction. (Linsenman, 1987) By storing the composition 
of the logical transaction in the tool box, the user is 
insured that all aspects of the transaction are dealt with 
whenever it is accessed. 

Other standard functions provided to the user by the 
CFESA are: help, data verification, transaction reporting 
(audit trail) , transaction activation, common transaction 
linkage between applications and functions, and standardized 
PF keys. 

A DSS based within the CFESA would provide added 
functionality to application developers in identifying the 
necessary components from the tool box for their 
application. The addition of a manpower and pay DSS to the 
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CFESA is expected to significantly reduce the time and 
effort that currently is required to develop end-user 
applications by reducing the time an application developer 
spends in identifying the components required for his/her 
application. It will provide a developer with a series of 
transactions that are applicable to the project he/she is 
working on based on the project specifications that the 
developer provides. The developer will then refine and 
combine the initial logical transactions to produce a 
prototype system for the user to evaluate and comment on. 
This will provide the developer with an immediate time 
savings at the beginning of a project by giving him/her a 
starting base for the application. Through the use of the 
Application Developers DSS and prototyping for developing 
new systems the user will be able to reap the benefits of 
his/her new application more quickly than under current 
development methods, and developers should finally be able 
to begin making headway against the backlog of development 
requests he/ she is currently facing. 

The primary components of a DSS within the CFESA would 
be the dialog component and a knowledge base to store the 
necessary information to drive the system outputs. These 
components can be easily incorporated into the structure of 
the CFESA. The menu structure of the CFESA environment 
provides an excellent mechanism for implementing a dialogue 
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with the user and the tool box of common functions provides 
a storage area for the knowledge base. 

The dialog component implemented within the CFESA menu 
structure would contain the essence of the system. The 
decision logic and rule processing would be contained within 
the user interface to determine the initial data 
requirements from the tool box. The user would be presented 
with a series of questions that he/she would have to respond 
to. Once all of his/her responses are entered, the system 
would utilize forward chaining to work through the 
statements contained within the inference engine of the DSS 
to determine the tool box access requirements. 

The knowledge base would be stored within the tool box 
of common functions in the form of data element 
relationships, standardized function modules and pre- 
programmed procedures that would be accessed based upon the 
results of the user/system dialog. These data element 
relationships, standardized function modules and pre- 
programmed procedures would provide the application 
developer with a knowledge base to build upon for the 
development of his/her application much faster than he/she 
could develop that knowledge base by sifting through 
reference manuals and other information sources. 
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IV. DECISION LOGIC & RULE PROCESSING 



The decision logic and rule processing used to drive the 
inference mechanism of a DSS comprises the data and dialog 
components of the Application Developers DSS. The inference 
mechanism is the bridge between the user and the 
model/knowledge base that leads the user to the information 
or knowledge that he/she needs to get from the 
model/knowledge base. Figure 4.1 shows the relationship 
between the user, inference mechanism, knowledge base and 
database . 

The inference mechanism drives all interaction within 
the system. Its function is to use the decision logic and 
rule processing to search through the knowledge base to 
provide information to a user. The inference mechanism is 
basically a set of routines that carry out deductive 
reasoning. It has no understanding what it is doing, or 
what it achieves. The process is simply a mechanical one. 
(Barrett and Beerel, 1988) 
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COMPONENT RELATIONSHIPS 



Figure 4.1 Component Relationship 

An inference mechanism is typically composed of a series 
of IF-THEN-ELSE statements that step the user through the 
decision making process to obtain the relevant information 
contained within the systems knowledge base. Information 
can be obtained from the knowledge base by using one of two 
methods of working through the decision logic and rule 
processing. The inference mechanism can use goal directed 
reasoning which is known as backward chaining or it can use 
data driven reasoning which is known as forward chaining to 
thread through the rules. With backward chaining, the goals 
are possible solutions to a specific problem and the system 
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works backward through the rules associated with each goal 
to determine if it is a viable alternative. Forward 
chaining uses the strategy of gathering data from a user 
until a pattern is recognized that will allow the system to 
present a user with a solution set. Forward chaining leads 
to a wider variety of solutions than does backward chaining 
since the possible solutions are not specified before hand. 
The chaining method used by a DSS depends upon the purpose 
of the DSS. Backward chaining is most useful in selecting 
between a set of known solutions, and forward chaining is 
used for building up solutions and leaps in reasoning. Each 
of these methods leaves a different impression on a user. 
Figure 4.2 shows a comparison between the two types of 
chaining. (Barrett and Beerel, 1988) 

Forward chaining is the logical choice when a system has 
to build up a solution from many components, or inputs. The 
Application Developers DSS would be such a system. The idea 
behind the system is to provide a developer with a set of 
data elements, procedures or functions that may be 
applicable to the application he/she is working on. Once 
the developer has a solution set to start with, he/she can 
begin to work on narrowing or expanding that base to provide 
all of the information or functionality that the application 
he/she is working on requires. 
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BACKWARD CHAINING 


FORWARD CHAINING 


Also called 


goal directed 


data driven 


Starts from 


possible solutions 


new data 


Works toward 


necessary data 


any conclusions 


Progression thru rules conclusion to 
condition 


condition to 
conclusion 


Style 


conservative 


opportunistic 


Processing 


efficient 


possibly wasteful 


User's Impression 


plodding but predictable 


responsive but quirky 


Obvious usage 


selection between alternative 
solutions 


building up solutions 
and 'leaps* In reasoning 




FORWARD VS. BACKWARD CHAINING 



Figure 4.2 Chaining Comparison 



The inference mechanism also provides a degree of self 
documentation to the system. This ability comes with the 
systems ability to track the rules that it uses to reach a 
conclusion or conclusions and to provide that list to the 
developer so that he/she can verify that the rules the 
system used are all applicable to the application he/she is 
developing. The inference mechanism also provides the 
ability to respond to basic type of questions the user asks 
such as why a particular rule was used. In this instance 
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the system would respond with the link that caused that 
particular rule to be used. This self documenting aspect of 
the system will enable an application developer to verify 
the outputs of the system more rapidly than he/she would be 
able to verify them if he/she didn't have them. 

One aspect of a forward chaining expert system type of 
DSS that is often looked upon as a drawback to them is the 
unpredictable nature of them. There is no guarantee with 
this type of system that a reasonable solution set will be 
arrived at. The solution set that the system provides may 
have no conclusions in it at all, or it may have an 
excessive number of conclusions, or an excessively large 
solution set. (Barrett and Beerel, 1988) While these may 
seem to be drawbacks in the beginning, a closer examination 
of the purpose of the Application Developers DSS shows that 
these results are actually an added benefit. A solution set 
that contains no recommendations for data elements, 
procedures or functions or one that is excessively large may 
actually be an indication that the application that the 
developer is working on has been poorly specified or poorly 
designed. Receiving an indication like this early in a 
projects life cycle should help to shorten the development 
time and improve the quality of the application as a whole. 
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V. MODEL/KNOWLEDGE BASE 



The model/knowledge base is the heart of an expert 
system type of DSS. It contains the know-how or expert 
information of the system that the inference mechanism must 
act with to reach a feasible solution based on the users 
input. The information contained in the model/knowledge 
base can come in any form, but it is usually expressed in 
the form of rules of thumb or relationships. The 
programming language used within the system most often 
determines the form the model/knowledge base will take. 
(Barrett & Beerel, 1988) 

The model/knowledge base within the Application 
Developers DSS will serve as the store house of the systems 
knowledge. It will hold the data relationships, procedures 
and functions that will comprise the outputs of the system. 

Access to the model/knowledge base will be controlled by 
the decision logic and rule processing utilized by the 
dialog component of the DSS. As stated earlier, the rules 
of the system are stored in the form of IF-THEN-ELSE type 
statements. This form is a familiar form to almost everyone 
literate in computers and makes the logic of the system 
relatively easy to understand. In an expert system type of 
DSS each rule is a nugget of know-how which is valid in 
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itself. When the system is running the inference mechanism 
will select which rules to apply, and when, to solve the 
current problem. The system builder only has to state what 
the rules are and not how the rules will be used. The 
statement- of what rather than how is a declarative statement 
of know-how and is one of the strengths of an expert system 
DSS . Other strengths include: 

• ability to add, modify, or delete rules independently of 
one another 

• ability to input rules in any order 

• program is easy to understand 

While these are generic strengths of an expert system 
DSS, there are some exceptions to them in reality. In many 
cases the order the rules are input often affects the 
processing, and the ease of understanding is often dependent 
on the software tools used and the skills of the person 
developing the system. 

When compared to traditional systems, an expert system 
type of DSS is usually quicker to build and easier to 
modify. It lends itself well to incremental development 
which gets a beginning product into the users hands faster 
and can be modified faster to provide what the user really 
wants because of the independent rules. (Barrett & Beerel, 
1988 ) 
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Another primary aspect of the model/knowledge base is 
the information it contains in the form of data 
relationships, canned procedures and standardized functions. 
In order for the Application Developers DSS to assist a 
developer in identifying all the aspects of a transaction or 
application it must contain intimate knowledge about what 
the relationships are among the data elements and how a 
change in one can effect other elements. Information like 
this can be expressed in the form of a complete, interactive 
data dictionary or an Entity And Attribute Report and 
Association Report (Information Engineering Systems 
Corporation, 1989) . 

Additionally, canned routines, procedures and functions 
should be available as an output from the system. These 
should come in the form of pre-coded and debugged modules 
that have proven to be effective in solving a rigidly 
specified task. These could include modules to change a 
service members marital status, promotion or stop/start an 
entitlement. The use of pre-coded modules like these in 
applications development will promote structured programming 
techniques, improve development speed and ease the 
documentation burden because each of the modules should be 
complete entities unto themselves, complete with test 
results and documentation to be included in the final 
package for the user. The only effort required by the 
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developer would be the function/procedure call and variable 
passing to get the data into and out of the module. 

In many cases, the sources for the standardized 
functions and procedures already exist in many 
organizations. Most programmers maintain their own private 
libraries of pre-coded modules that execute what they have 
found to be repetitive or commonly used tasks. By tapping 
these libraries significant time in loading the 
model/knowledge base can be saved and many programmers would 
feel that they have a vested interest in the system since 
they would have made a contribution to it. This aspect will 
go a long way toward tapping the pool of expert knowledge 
throughout an organization. 
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VI. FUNCTIONAL REQUIREMENTS DEFINITION 



This chapter contains the Functional Requirements 
Definition of the Application Developers DSS and is 
formatted in accordance with Marine Corps Order P5231.1A and 
IRM 5231.04. 

SECTION 1 GENERAL 

The Marine Corps Central Design and Programming 
Activity, Kansas City, Mo. is currently installing a new 
architecture for their mainframe environment to operate 
under that is known as the Common Front-End System 
Architecture. This architecture gives an application 
developer working within the manpower and pay arena a single 
system image environment to operate within and provides 
him/her with access to a tool box of common functions to use 
in developing applications. 

This specification describes a DSS for use on the CFESA 
that will aid an application developer in identifying 
applicable data elements, functions, and procedures for use 
in a program being developed. 
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1.1 OBJECTIVES 



The Application Developers DSS design objectives are: 

a. Provide application developers working within the 
CFESA with an automated aid for identifying data 
elements, functions and procedures that could be 
applicable to a program under development. 

b. Save time during the development phase of a 
programming project. 

c. Guard against the loss of knowledge in the event 
the "duty expert" leaves the installation. 

1.1.1 Current System Deficiencies 

The current method of identifying applicable data 
elements, functions, and procedures to use within a 
programming project leads to several deficiencies. Among 
them are: 

a. Excessive time spent searching through unrelated 
literature . 

b. Distracting knowledgeable programmers from their 
assigned tasks. 

c. Missing related data elements, functions, or 
procedures due to lack of recognizing their 
applicability. 

d. Loss of corporate information when experienced 
programmers leave the installation. 
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1.1.2 Proposed System Objectives 



The primary objective of the Application Developers DSS 
is to provide application developers working within the 
CFESA architecture an automated tool to speed up the 
identification of data elements, functions, and procedures 
that need to be considered for use within a programming 
project. The system will use the components of the CFESA 
architecture to query an application developer about the 
focus of a programming project and use the results to search 
through the tool box of common functions to obtain a 
beginning set of data elements, functions, and procedures 
that should be considered as applicable to the project. At 
that point the application developer must determine which of 
the items is actually applicable to the project and use them 
accordingly. 

1.2 SCOPE 

The Application Developers DSS will be limited to the 
manpower and pay functional areas that are within the domain 
of the MCCDPA Kansas City, Mo. 
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1.2.1 Applications Under Study 



The Application Developers DSS will be limited to 
application development in the manpower and pay functional 
areas. All of the deficiencies identified in Section 1.1.1 
are directly related to the amount of time spent gathering 
information and the accuracy, completeness, and relevance of 
the information. 

1.2.2 Organizational Environment 

The organizational environment the system will function 
within is the environment within the Marine Corps Central 
Design And Programming Activity, Kansas City, Mo. 

1.2.3 Site Specific Information 

The system will run within the hardware and software 
environment delineated previously in Table 3.2. 

1.3 AUTHOR 

Captain Charles C. Hansen, USMC 

Student, Computer Systems Management Curriculum 
Naval Postgraduate School 
Monterey, Ca. 93943 
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1.4 FUNCTIONAL REQUIREMENTS DEFINITION ACTION PLAN 



The Application Developers DSS represents a new type of 
development activity for the MCCDPA Kansas City, Mo. It 
will replace a manual search of system reference manuals, 
data dictionary entries, previously developed programs, and 
corporate knowledge held by other members of the 
organization with an automated tool that will focus on the 
primary area of a development project. 

1.4.1 New Logical Model Findings 

The CFESA provides an excellent environment for a DSS to 
operate within. It provides: 

a. A well defined method of user interface to handle 
the dialog component of a DSS. 

b. A tool box for the storage of data element 
relationships, functions, and procedures to fill the 
needs of the model component of a DSS. 

c. A temporary work area for the system to use as the 
data component to compile the results of the 
user/system dialog and search the model component to 
identify the applicable information. 
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1.4.2 Recommended Course of Action 



The ability of the CFESA to meet the needs of a DSS 
indicates that development of a DSS for application 
developers working within the CFESA should be undertaken. 
DSS development requires a different approach than 
traditional system development utilizes in order to be 
successful. Past experiences in DSS development indicate 
that an incremental approach to development through the use 
of prototypes works best. (Sprague and Carlson, 1982; 
Turban, 1988) 

Based on the findings, incremental development of the 
Application Developers DSS should continue through the use 
of prototypes. 
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SECTION 2. STRUCTURED SPECIFICATION 



2.1 DATA FLOW DIAGRAMS (DFD) 

The DFD's for the Application Developers DSS are 
depicted in the following sections. 

2.1.1 Context Diagram 

FIGURE 7-01 Application Developers DSS Context Diagram 
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2.1.2 Leveled Set of Diagrams 
2. 1.2.1 Level-One Diagram 

FIGURE 7-02 Application Developers DSS Logical Model 




Application Developer’s DSS 
Logical Model 



Figure 7-02 Logical Model 
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2. 1.2. 2 Level-Two Diagrams 

FIGURE 7-03 Application Developers DSS Dialog Component 
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FIGURE 7-04 Application Developers DSS Data Component 




Application Developer’s 
Data Component 



Figure 7-04 Data Component 
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2 . 2 MINI-SPECIFICATIONS 



2.2.1 Mini-Specification Descriptions 

2. 2. 1.1 1.0 Application Developers DSS Dialog Component 

1.1 Obtain Functional Area Info 

1.2 Obtain Event Info 

2.2. 1.2 2.0 Application Developers DSS Data Component 

2.1 Identify Data Elements 

2.2 Identify Functions 

2.3 Identify Procedures 

2.2.2 Level -One 

2.2.2. 1 Process 1.0 Application Developers DSS Dialog 
Component 

2. 2. 2. 2 Process 2.0 Application Developers DSS Data 
Component 

2.2.3 Level -Two 

2. 2. 3.1 Process 1.1 Obtain Functional Area Info 
This process is the initial component of the dialog 
component for the DSS designed to obtain the desired 
functional area from the user. Information obtained in this 
process is used to determine the queries available in the 
next process. 

Query user for applicable Functional Area 
Accept user input for Functional Area 
Pass Functional Area to Process 1.2 
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2. 2. 3. 2 Process 1.2 Obtain Event Information 



This process uses the Functional Area information obtained 
in Process 1.1 to determine the relevant event information 
to query the user about that will eventually be used to 
select applicable data elements, functions, and procedures. 
Do while not done 

Query user for applicable events based on Functional 
Area 

Accept event input from user 
End-do 

Output Functional Area/Event info to Process 2.0 

2. 2. 3. 3 Process 2.1 Identify Data Elements 

This process takes the data assembled in the data component 
of the Application Developers DSS and uses the information 
to search the tool box of the CFESA for data elements that 
may be applicable to a developers application that is under 
development . 

Accept FA/Event data 

Search tool box for applicable data elements 
Store applicable data elements for output to user 
Pass FA/Event data to Process 2 . 2 

2. 2. 3. 4 Process 2.2 Identify Functions 

This process takes the data assembled in the data component 
of the Application Developers DSS and uses the information 
to search the tool box of the CFESA for functions that may 
be applicable to a developers application that is under 
development. 

Accept FA/Event data 

Search tool box for applicable functions 
Store applicable functions for output to user 
Pass FA/Event data to Process 2.3 



53 



2. 2. 3. 5 Process 2.3 Identify Procedures 

This process takes the data assembled in the data component 
of the Application Developers DSS and uses the information 
to search the tool box of the CFESA for procedures that may 
be applicable to a developers application that is under 
development . 

Accept FA/Event data 

Search tool box for applicable procedures 
Store applicable procedures for output to user 
Discard FA/Event data 

2.3 DATA DICTIONARY 

The data dictionary developed and defined by the REAL FAMMIS 
project is applicable and requires no changes. 



SECTION 3 SUPPORTING DOCUMENTATION 
3.1 SUMMARY OF NEW REQUIREMENTS 

The new requirements of the Application Developers DSS 
lie in the area of the data, dialog, and model base 
components of a DSS. These components make up the heart of 
a DSS and specific information concerning each component as 
it relates to the Application Developers DSS is contained in 
Chapter 7 . 
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VII. CFE8A SYSTEM INTEGRATION 

The CFESA is the key ingredient in the development of 
the Application Developers DSS. It provides an excellent 
environment to support the data and dialog components of the 
DSS as well as a ready made store house for the model base 
in the form of the tool box. All of the interfaces between 
these components have already been designed within the 
CFESA, as well as additional features that make the user's, 
application developer's, and system administrator's jobs 
easier to master. 

Tieing a DSS into the CFESA will require care and 
attention to be applied to each individual component. Each 
of the DSS components, Data, Dialog and Model Base, has its 
own particular areas of concern that need to be addressed 
directly . 

A. DATA COMPONENT 

The Data Component of the DSS is where all of the 
decision making of the DSS will occur. For the Application 
Developers DSS it contains the rule base the system 
functions on and temporary working storage for use while the 
users input is being accumulated and then to store and 
format the results of searching the tool box (Model Base) 
for data elements, functions and procedures that might be 
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applicable to a developers project. In an environment where 
virtual memory is used, such as that found at the MCCDPA, 
concern over each users available work area is minimized 
thanks to the dynamic way in which memory is allocated to 
each user* In installations where virtual memory is not 
utilized, or there are other restrictions imposed upon 
user's memory use, care should be taken to allocate 
sufficient memory to allow for the efficient processing of 
the system. If there isn't enough memory allocated to allow 
for smooth, efficient operation the system will appear slow 
and awkward to a user and will result in a lack of 
confidence in the responses the system provides and 
eventually use of the system will cease. (Barrett and 
Beerel, 1988) 

The rule base, in the form of IF-THEN-ELSE statements, 
contains the reasoning ability of the DSS. They are an 
attempt to isolate the reasoning that an experienced 
programmer might utilize to break down a programming project 
to identify the data elements, functions and procedures that 
should be utilized for the project. The rule base for the 
Application Developers DSS is based on the structure and 
information available within the manpower and pay database. 
The initial determination that a user will have to make is 
whether the primary area of concern is within the manpower 
or pay area, or both. The possibility that a transaction 
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will effect both areas must be considered since there is a 
large area of overlap between the two functional areas. 

Once this determination has been made, the specifics of the 
application are addressed. During the development of the 
Real FAMMIS Reporting and Retrieval System (R3S) , sixteen 
basic categories were identified as valid transaction 
categories. These sixteen categories are: 

• Join 

• Drop 

• To 

• From 

• Training 

• Dependents Information 

• Pay (Debits/Credits) 

• Discipline 

• Performance 

• Service Information 

• Contract Information 

• Personal Information 

• Basic Individual Record Audit 

• Unit Information (Events) 

• Checklist for Personnel Reportable Items 

• Checklist for Pay Related Reportable Items (Planning 
Analysis Corporation, 1988) 
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Each of these sixteen categories leads to more detailed 
information that eventually identify disbursing Type 
Transaction Codes (TTC) that can be associated with 
individual data elements, functions, and procedures. 

B . DIALOG COMPONENT 

The Dialog Component of the DSS will represent the whole 
DSS to the user. It will be the only part of the 
Application Developers DSS that the user actually sees, 
therefore it is crucial that the User/System dialog operate 
smoothly and efficiently. 

The primary purpose of the Dialog Component is to gather 
information from the user that the system can use to search 
through the Model Base. The information will be gathered 
through an interactive User/System dialog that presents a 
user with a series of questions to respond to. The 
questions that the system poses to the user come from the 
rule base that is designed into the system. Since the goal 
of the Application Developers DSS is to provide a developer 
with a set of possible data elements, functions and 
procedures for use in a program, the system must use forward 
chaining to progress through the rule base. 

A forward chaining inference mechanism is often 
difficult to initiate and, as noted earlier, often appears 
quirky to the user. Despite this, it is the only method to 
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achieve the desired results. Since the decisions that the 



system must handle are straight forward questions with clear 
cut answers some of the awkwardness will be removed from the 
system. The ability to limit the system to clear cut 
questions and answers removes the necessity of identifying 
confidence factors for the rules. This makes the system 
much easier to program. Rather than looking for the most 
relevant of many possible rules to utilize, the system can 
be lead directly to the next rule. Since the Application 
Developers DSS has many different branches that can be 
traversed, the sequence of events is best handled by a case 
structure. At each level of decision the system should 
present a list of relevant events for a user to choose from. 
Each choice will lead to another subset until the ability to 
divide the event is exhausted and the system arrives at a 
recommended list of TTC's. 

The Dialog Component will also have the ability to draw 
upon the capabilities of the CFESA to further enhance its 
interaction with a user. The event choices available to any 
developer can be further refined based upon that users level 
of access contained within the CFESA' s security 
authorization mechanism. This will prevent a user with Read 
Only authority from developing an application that would 
allow him/her to make changes to the database by denying 
him/her access to the functions and procedures that allow 
those changes to be made. 
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C. MODEL BASE 



The Model Base for the Application Developers DSS is 
composed of the data elements, functions and procedures that 
relate to the manpower and pay functional areas. Most of 
the work necessary to accumulate this model base has already 
been done, in one form or another. 

1. Data Elements 

The Manpower and Pay Functional Managers modeling 
teams have expended much time and effort in designing the 
Real FAMMIS database. Through the use of Computer Aided 
Systems Engineering (CASE) technology a database containing 
857 entities and 1124 associations has been identified. The 
data dictionary for this database should comprise the data 
element portion of the Application Developers DSS model 
base. 
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2. Functions and Procedures 

Much of the work compiling functions and 
procedures that are applicable to certain events has already 
been accomplished by programmers throughout the MCCDPA 
Kansas City. Most programmers are in the habit of 
developing and maintaining libraries of these types of 
routines. Use of these libraries saves programmers time and 
machine time since they are already coded and debugged. The 
only difficulty in obtaining these routines is getting the 
organizations programmers to submit them for inclusion in 
the model base. 

The biggest concern within the model base is developing 
a method to identify which functions and procedures are 
applicable to which events/data elements. One method of 
identification would be through the use of the TTC's that 
are already linked to the data elements. Utilizing this 
method would provide the easiest method of association and 
would only require limited expansion or creation of TTC's to 
identify higher level events. Adding these codes to the 
headers of each function and procedure would allow easy 
identification of applicable items based on the results of 
the user/system dialog. 
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Another important ability that the model base must 
possess is the ability to grow and adapt to changes. If the 
model base is to stay relevant, this ability must exist. A 
key consideration to an organization is where the authority 
to make changes to the model base should lie. In order to 
effectively address this problem, the position of Model Base 
Administrator (MBA) should be created. The MBA's duties and 
responsibilities would parallel the duties and 
responsibilities of a Data Base Administrator as found in 
many organizations. The MBA should be in a position to work 
closely with the organization's DBA and possess an intimate 
knowledge of the functional areas requirements and purposes 
so that he/she can insure that the model base stays current. 



62 



VIII. CONCLUSIONS AND RECOMMENDATIONS 



A. CONCLUSIONS 
1. General 

The development of the Application Developers DSS 
provides the MCCDPA Kansas City, Mo. with the opportunity to 
increase programmer productivity and to gain additional 
benefits from work that has previously been accomplished by 
the Real FAMMIS program office. It will build on work that 
went into the Event Reporting for the R3S system and utilize 
the basic design work of the Real FAMMIS project as well as 
utilize the capabilities of the CFESA. Since the 
Application Developers DSS will be make use of a new 
architecture at the MCCDPA it is difficult to assess the 
viability and benefits such a system could provide. Based 
on the results obtained at the DOE INEL and the potential to 
realize a significant time savings in the early stages of 
program development, the Application Developers DSS gives 
every indication of being a system that could provide 
enormous benefits through increased programmer productivity 
to the MCCDPA. 
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Without the CFESA, development of the Application 
Developers DSS would be much more difficult. Extensive work 
would be required on the interfaces between the data, dialog 
and model base components. Working within the CFESA though 
relieves the interface burden from the DSS developer and 
allows him/her to concentrate upon the task of defining the 
rules and establishing the model base. 

2 . Inference Mechanism 

The inference mechanism driving the Application 
Developers DSS will appear as a menu system displayed by the 
system that allows a user to select the next level choice 
from a list provided to him/her. Beginning the inference 
mechanism in this manner will allow development to take 
place incrementally on the system and for more time to be 
spent on the tool box contents than on the access method. 
Once the tool box contents have been finalized and initial 
feedback has been achieved, a more elaborate processing 
scheme for the inference mechanism can be developed and 
installed for the Application Developers DSS. 

3 . Model Base Components 

The real effectiveness of the system lies in the 
contents of the CFESA tool box. In order for the system to 
be utilized the developers who are going to be accessing it 
must believe in the integrity of the data elements, 
functions and procedures it contains. Initial loading of 
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the tool box contents should receive a high priority during 
the system development. Utilizing the information developed 
during the Real FAMMIS information engineering effort and 
further incorporating the results obtained from Information 
Engineering Systems Corporation's User: Expert System 
software package, should provide the initial confidence in 
the data element components within the tool box. The same 
level of confidence in the functions and procedures can be 
obtained by carefully reviewing each one submitted for 
inclusion and thoroughly testing and documenting each one 
before it is added to the tool box. 

Continued confidence in the integrity and value of the 
items in the tool box can only come from a demonstrated 
commitment to keeping the items up to date and accurate. 

This can be accomplished by establishing a Model Base 
Administrators (MBA) position at a level of authority equal 
in degree to that of the Data Base Administrator (DBA) . The 
duties of the MBA would be similar to those of the DBA in 
that he/she would be responsible for insuring the integrity 
of the items in the tool box and be the central point for 
changes that would be included in them. 
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B. RECOMMENDATIONS 



The Application Developers DSS represents an opportunity 
for the MCCDPA Kansas City, Mo. to realize additional 
benefits from previously accomplished work and advance into 
new areas of program development. As such, the following 
recommendations are provided: 

• Determine to begin incremental development of the 
Application Developers DSS after the installation of the 
CFESA is complete at the MCCDPA Kansas City, Mo 

• Begin collection, identification and documentation of 
standardized functions and procedures for inclusion in 
the tool box 

• Create the position of Model Base Administrator and 
staff it at the appropriate level 

• Expand upon the TTC identification scheme and utilize it 
to identify the data elements, functions and procedures 
contained in the tool box 

• General and Detail Design efforts for the Application 
Developers DSS should begin as soon as possible 
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Appendix A 



Spider Diagrams 
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The diagrams contained on the following pages contain 
the event sequences for the JOIN event leg of the menu's. 
These diagrams correspond with the diagrams contained in 
Appendix B as noted below each diagram. 
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Level 2 JOIN Event 
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Level 2 JOIN Event (Part 1 of 3) 
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Level 2 join Event [Part 2 of 3) 
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Level 2 JOIN Event (Part 3 of 3] 
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Level 3 join Event (Part i of 2] 
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Level 3 JOIN Event (Part 2 of 2) 
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Level 3 JOIN Event 
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Level 3 Join Event 
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Level 3 Join Event 
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Level 3 JOIN Event 
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Level 3 join Event 
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Level 3 JOIN Event 
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Level 3 JOIN Event 



See Appendix B, 



Page B-4 . 



A-33 



Appendix B 



Screen Maps 



The diagrams contained in this appendix are taken from 
the REAL FAMMIS Event Reporting document prepared by 
Planning Analysis Corporation. They are included here for 
ready reference and correlation with Appendix A. 
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